Debugging software (e.g., done with debugger equipment) effectuates correction of problems in software by finding errors in program logic, and in hardware by finding errors in circuitry. Debuggers stop programs at certain breakpoints and display various programming elements regarding the machine's internal state. This allows programmers to step through program source code statements individually and sequentially, while corresponding machine instructions are being executed and observed, and correct and/or modify the code as necessary.
Debuggers may deploy an in-circuit emulator (ICE) to follow certain functions and features of a device, such as a microcontroller or other integrated circuit (IC). The ICE thus allows debugger software to place code within a device under test, set breakpoints and other debugging functions therein, and prompt the device under test to implement supervisory and other debugging operations. These ICE functions further allow the debugger software to “look into” memory, registers, and other internal resources of the device under test to observe the effects corresponding to the execution of the program code.
An IC device, such as a microcontroller, may be deployed upon a pod for testing. The pod electrically interconnects the microcontroller or other IC to be tested with the ICE. There are many varieties of microcontrollers and other IC's in existence and under development. Information may change with each different device. Such information may include the way in which decoding of supervisory operational codes are performed. The types of information that might change with each different device may also include the reset sequence of the device. Further, the types of information that might change with each different device may include the way in which the device is programmed.
As a result, separate ICE's are typically required for each different microcontroller or other IC that needs to be tested and debugged. Further, if the same microcontroller or other IC to which a particular ICE corresponds is deployed upon a different pod, yet another separate ICE may be required. In general, a particular emulator is limited to operating with a single type of microcontroller or other IC.
A user of a conventional debugging system, may thus be forced to access and maintain a variety of different ICE's for each and every microcontroller or other IC they test. Also, each time a user of a conventional debugging system changes the microcontrollers or other ICs to be tested, they must acquire the corresponding ICE. Further, a user of a conventional debugging system who is developing new microcontrollers or other ICs must develop corresponding ICEs to test them. A user may thus find a conventional debugging system problematic for a number of reasons.
For instance, a conventional debugging system may require access to a variety of different ICEs for each and every microcontroller or other IC they must test. This may limit the flexibility of the conventional debugging system, especially when microcontrollers or other ICs in use change. Also, ICEs are not inexpensive, and upon acquisition, they must be properly selected, stored and maintained. This adds expense to the cost of a debugging system.
As new microcontrollers or other ICs are developed, a unique, corresponding ICE must be also be individually developed to some degree. This adds complexity to the development of the associated microcontroller or other IC. It also affects the cost of development of that device. This is because the cost of developing the associated ICE must be factored in with that of the development of the microcontroller or other IC, adding to their expense, also.
Each version must also be correctly matched to a particular pod and/or microcontroller or other IC. This adds complexity to the debugging or other test process in general, and to the component matching process in particular. These problems render debugging in a distributed hardware environment by conventional means expensive, time consuming, resource intensive, and laborious.